Understanding A2A — The Protocol for Agent Collaboration

[laxmih]

The world of AI is undergoing a transformation — one where specialized agents, each crafted for narrow tasks, are proliferating rapidly. But with this specialization comes a challenge: how do these agents talk to each other?

Google’s Agent2Agent (A2A) protocol, introduced in April 2025, offers a promising answer. In this article, we’ll dive into A2A’s architecture, the problem it solves, and why it might just be the universal language of AI agents.

🌍 The Interoperability Challenge: Why AI Agents Can’t Collaborate (And Why They Need To)

Each AI agent is often built with its own framework, language, and API assumptions. Enterprises adopting these agents are left building custom integrations — every pair of agents needs a bridge. As more agents enter the mix, the integration effort explodes:

Integration complexity grows at O(N²) — a classic scaling nightmare.

This isn’t just theory. It’s a daily reality for teams: spending weeks writing “glue code” instead of innovating. Bugs multiply. Systems become brittle. New agent adoption slows down. Without a shared language, intelligent collaboration is impossible.

🔗 Introducing A2A: Google’s Blueprint for Agent-to-Agent Communication

Agent2Agent (A2A) is an open protocol designed to let AI agents communicate, collaborate, and coordinate — securely and seamlessly. Created with input from over 50 industry partners, A2A is more than a Google tool: it’s an industry-wide foundation for multi-agent ecosystems.

With the rollout of the new version of the A2A protocol specification, key enhancements have been incorporated. This includes support for stateless interactions, an update that simplifies development for scenarios where session management isn’t needed, leading to more efficient and lightweight communication. Furthermore, version 0.2 brings standardized authentication by formalizing authentication schemes based on an OpenAPI-like authentication schema. This ensures clear communication of authentication requirements across agents, bolstering security and reliability in agent-to-agent interactions.

With A2A:

• Agents can dynamically discover each other
• Collaborate via standardized tasks
• Share multi-modal content
• Handle long-running processes
• Do all this with enterprise-grade security

🧱 A2A Building Blocks: What Every Developer Should Know

The A2A protocol structures interactions between agents through a set of well-defined components. These components collectively establish how agents can discover each other’s capabilities, initiate and manage collaborative work, and exchange information in various formats. Understanding these building blocks is essential for any developer looking to implement or interact with A2A-compliant agents.

📇 Agent Card: The Digital Business Card

Central to A2A’s discovery mechanism is the Agent Card. Functioning as a public, machine-readable JSON metadata document, it serves as an agent’s digital “business card,” advertising its identity and capabilities to potential clients. Typically published at a well-known URI, often /.well-known/agent.json, the Agent Card is crucial for enabling agents to find and understand how to interact with one another.

The Agent Card advertises key information such as:

• Identity and Description: Details about the agent itself.
• Service Endpoint: The specific URL where the A2A server can be reached.
• Authentication Requirements: With the v0.2 enhancements, the Agent Card formally includes details on supported authentication schemes. This often aligns with OpenAPI Authentication methods (e.g., “Bearer” for OAuth 2.0 tokens, “Basic” for Basic Auth, or “ApiKey” for API keys), allowing clients to discover precisely how to securely connect.
• Capabilities: Information about the agent’s operational features, such as its support for streaming (capabilities.streaming: true) or push notifications (capabilities.pushNotifications: true).
• Skills: The specific tasks or functions the agent is proficient in and offers to other agents.

Much like robots.txt guides web crawlers or service registries help in microservice architectures, the Agent Card enables automatic discovery and understanding of an agent's offerings and interaction protocols, significantly reducing the need for hardcoded integrations and fostering dynamic collaboration.

🧩 Task: The Unit of Collaboration

In the A2A protocol, when a client sends a message to an agent, the agent might determine that fulfilling the request requires a stateful operation (e.g., “generate a report,” “book a flight,” “summarize a document”). This is where the Task Object comes into play. It is the fundamental, stateful unit of work processed by the A2A Server (remote agent) for an A2A Client, encapsulating the entire interaction related to achieving a specific goal or request.

Key characteristics of a Task include:

• Initiation and Identification: A Task is typically initiated based on a client’s request. The remote agent then creates and manages the Task, assigning it a unique, server-generated id (often a UUID). Many A2A interactions revolve around this Task and its id.
• Progresses through a defined lifecycle of states: submitted (Task has been received), working (Agent is actively processing the task), input-required (Agent needs more input to proceed), completed (Task finished successfully), failed (Task could not be completed due to an error), canceled (Task was terminated by the client or system)
• Interaction History: A Task is stateful and can involve multiple exchanges. It can contain a sequence of Messages (often in a history field), representing the conversational turns between the client and the agent within the context of that task.
• Outputs: A successfully completed Task typically produces one or more Artifacts — the immutable results or outputs of the agent's work (e.g., a generated summary, a file, an image, or structured data).
• Orchestration and Context: While individual tasks are fundamental, A2A also supports more complex scenarios. For instance, the A2A Python SDK includes features like a “request context builder with referenceTasks". This indicates capabilities within the A2A ecosystem to link and manage interdependent tasks, allowing for sophisticated orchestration where the context or outcome of one task can influence another. A Task object itself often includes a contextId to help group related tasks.

By defining interactions within the framework of Tasks, A2A provides a standardized way to manage both simple and complex collaborative efforts between AI agents.

💬 Message: The Conversational Turns

Messages represent individual turns of communication within a Task’s context. They carry content like the initial request, subsequent inputs, status updates, or intermediate reasoning steps from the agent. A crucial field is role, designating the originator as either "user" (client agent) or "agent" (remote/server agent). Each Message contains one or more Parts holding the actual content.

🧱 Part: The Fundamental Content Units

Parts are the elemental units of content within Messages or Artifacts. Each Part is self-contained, specifying its content type (MIME type) and associated metadata. The protocol defines basic Part types like TextPart (plain text), FilePart(binary data, either base64-encoded or via URI), and DataPart (structured JSON data).

The concept of Parts is foundational to A2A's support for multi-modal communication. It allows agents to exchange not just text but also files and structured data, and potentially richer media as the protocol evolves. This is critical as AI moves beyond purely text-based interactions. The explicit content typing enables agents to negotiate appropriate formats and even discuss client UI capabilities, making A2A future-proof for richer, more complex real-world agent interactions involving diverse data modalities.

📦 Artifact: The Result

Artifacts are the immutable results or outputs generated by an agent during a Task’s execution. A single Task can produce multiple Artifacts, such as generated documents, structured data summaries, or images. Like Messages, Artifacts are composed of one or more Parts, allowing outputs to be multi-modal.

🔔 Secure Notifications: Decoupled & Enterprise-Ready

A2A includes a robust notification mechanism that allows agents to send task updates even when the client is no longer connected — using a component known as the PushNotificationService.

In enterprise settings, security is paramount. The A2A Server (remote agent) must authenticate itself to the client’s webhook URL when sending a push notification. This is typically achieved using JSON Web Tokens (JWTs).

• The A2A Server generates a JWT, signing it with its private key.
• This JWT includes claims such as issuer (iss), audience (aud - the webhook URL), issued at (iat), expiration time (exp), JWT ID (jti), and the taskId.
• The JWT header specifies the signing algorithm (alg) and key ID (kid).
• The A2A Server makes its public keys available via a JSON Web Key Set (JWKS) endpoint, allowing the client's webhook receiver to retrieve the public key and verify the JWT's signature.

The client, upon receiving a notification at its webhook:

• Authenticates the incoming notification by verifying the JWT.
• Validates the notification’s relevance (e.g., checking an optional client-generated token that the server includes in the notification if provided in the PushNotificationConfig).
• Relays the notification or its content to the appropriate client application logic.

Importantly, the PushNotificationService is treated as an independent, intermediary system — it’s not assumed to be the client itself. Instead, it acts as a trusted proxy that:

• Authenticates and authorizes incoming notifications from agents
• Forwards the message to the appropriate destination — which could be a pub/sub system, an email service, or even a downstream API

In lightweight or isolated deployments (e.g., a tightly scoped VPC or local service mesh), a client might choose to host its own push service. But in real-world enterprise implementations, this role is typically handled by a centralized, secured notification layer — much like mobile push notification infrastructures.

This model ensures that A2A can support reliable, authenticated, and decoupled communication across networks and deployment architectures.

📌 TL;DR

📡 A2A Under the Hood: Technical Architecture & Communication Flow

To understand how A2A enables seamless agent collaboration, it’s important to look beneath the surface. The protocol’s design is rooted in familiar, web-native technologies, making it easier for developers to integrate into existing enterprise systems without a steep learning curve.

A2A’s communication stack relies on three core technologies:

• HTTP(S) — The foundational transport layer. All production deployments require secure HTTPS with modern TLS encryption, ensuring privacy and integrity in transit.
• JSON-RPC 2.0 —A lightweight, JSON-based remote procedure call format used for invoking A2A methods like message/send. It standardizes how agents request and respond to actions.
• Server-Sent Events (SSE) —For real-time, server-to-client communication (especially in streaming scenarios like message/stream), A2A opts for SSE over WebSockets. This decision reflects a practical trade-off: SSE is unidirectional, firewall-friendly, and easier to implement for common use cases like task updates. While WebSockets allow bidirectional communication, A2A prioritizes simplicity for scenarios where streaming is mostly one-way.

Together, these choices reflect a protocol built not just for power, but for practical deployment at scale — with minimal friction for enterprise developers.

A typical A2A interaction follows a structured sequence :

1. Discovery: The client agent fetches the remote agent’s Agent Card from /.well-known/agent.json to learn its capabilities, endpoint, authentication, and communication modes.
2. Initiation: The client generates a unique Task ID and initiates the task by sending an initial Message. This uses either:
   • message/send: For synchronous interactions or when the client intends to poll for updates using tasks/get for longer-running tasks.
   • message/stream: For establishing a streaming connection for real-time updates via Server-Sent Events (SSE), suitable for long-running tasks or when incremental results are beneficial.
3. Processing: (Streaming):(Streaming): Server sends SSE events (status updates, artifacts) as the task progresses. (Non-Streaming): Server processes the task synchronously and returns the final Task object in the response, or the client polls using tasks/get.
4. Interaction (Optional): If the remote agent needs more information, it transitions the Task state to input-required. The client can then send subsequent Messages with the requested input.
5. Completion: The Task concludes with a terminal state: completed, failed, or canceled (client-requested via tasks/cancel or server-terminated).

The reliance on ubiquitous standards like HTTP, JSON, and SSE significantly reduces the learning curve and implementation overhead for developers, as they are likely already familiar with these technologies and possess existing tools and libraries.

⏳ Handling the Spectrum of Tasks: From Quick Queries to Long-Running Sagas

A2A is built to support the full range of task complexity — from rapid-fire API-style requests to long-running workflows that may take hours or involve human input along the way.

The protocol distinguishes between two core interaction patterns:

• message/send: For tasks where a synchronous response is expected or when the client will poll for updates.
• message/stream: For tasks that benefit from real-time progress updates via Server-Sent Events (SSE).

In streaming mode, agents can emit events such as:

• TaskStatusUpdateEvent – to signal lifecycle changes (e.g., working → completed)
• TaskArtifactUpdateEvent – to share intermediate or final outputs as they become available

To support robust task management, A2A also includes:

• tasks/get: for clients to poll task state if they aren't using streaming
• tasks/cancel: to terminate a task on demand
• tasks/pushNotification/set: to register a webhook for async updates when clients can’t maintain a persistent connection

This dual mechanism — SSE for connected clients, webhook based Push Notifications for disconnected or background environments — gives developers the flexibility to build agents that gracefully handle both real-time and asynchronous execution, even across network interruptions or device constraints.

Whether you’re orchestrating a chatbot conversation or automating a multi-step enterprise process, A2A ensures your agents can keep pace — no matter the complexity or duration of the task.

💡 The Payoff: Why A2A Matters for Developers and Enterprises

The value of the A2A protocol lies in what it fundamentally unlocks: true interoperability in a world of fragmented AI systems. By providing a common communication standard, A2A breaks down the barriers between agents built with different frameworks, languages, or vendor ecosystems — effectively acting as a “universal passport” for agent collaboration. The introduction of the official A2A Python SDK further empowers developers by providing concrete tools to implement these communication capabilities, making the benefits of A2A more tangible and easier to achieve.

🛠️ For Developers: Less Glue Code, More Innovation

A2A, especially when leveraged via the official A2A Python SDK, simplifies the development of multi-agent systems in several powerful ways:

• Streamlined Integration
  Say goodbye to brittle, one-off connectors. A2A reduces the need for custom glue code and bespoke APIs for every agent-to-agent interaction.
• Modular & Composable Architectures
  Developers can build specialized agents independently, then plug them into larger workflows with ease — much like microservices. This encourages rapid iteration and more maintainable system design.
• Flexibility & Runtime Discovery
  Because agents advertise their capabilities dynamically, developers can chain together services at runtime. This means fewer hardcoded dependencies and more freedom to mix and match agents from different providers.

🏢 For Enterprises: Scalable, Cost-Efficient AI Automation

Enterprises stand to benefit from A2A’s standardization in ways that go far beyond technical elegance:

• Smarter Automation
  A2A enables the automation of complex, multi-step processes across tools, teams, and platforms — unlocking deeper productivity gains.
• Scalability Without Rework
  New agents can be added without overhauling your architecture, making A2A a foundation for truly scalable AI ecosystems.
• Faster Time-to-Value
  By reducing integration effort, businesses can ship AI-powered solutions faster and iterate more rapidly.
• Lower Costs & Less Lock-In
  A2A’s open standard reduces both development and maintenance overhead — and makes it easier to avoid vendor lock-in.
• Unified Governance
  A consistent framework for managing agent interactions simplifies orchestration, auditing, and policy enforcement across diverse environments

🚀 Beyond Basic Chat: A2A’s Advanced Capabilities & Future-Proof Design

While many AI protocols stop at simple message passing, A2A is built for much more. It’s designed to support sophisticated, interactive agent workflows — now and in the future.

One of its standout strengths is support for long-running tasks. Whether a process takes seconds, hours, or even days — and possibly involves human input along the way — A2A is equipped with real-time status updates, feedback mechanisms, and notification systems to keep all parties in sync.

But perhaps the most forward-looking aspect of A2A is its modality-agnostic design. Unlike text-only standards, A2A supports a broad range of content types using typed Parts:

• TextPart for plain text
• DataPart for structured JSON
• FilePart for binary files, documents, or media

Crucially, A2A is future-ready with built-in provisions for audio and video streaming — anticipating the shift toward multi-modal AI. As AI moves into domains like image generation, speech analysis, and video summarization, A2A’s architecture allows agents to seamlessly exchange diverse data types.

This makes it ideal for real-world agent applications that go far beyond chat — think:

• Digital workspaces where agents collaborate with users across formats
• Agents that handle voice input, generate PDFs, summarize spreadsheets, and more
• Embodied or embedded AI agents that support rich interactions over time

And all of this is built on a foundation of security by design:

• HTTPS/TLS is required in production
• Agent Cards declare supported authentication methods (e.g., OAuth 2.0, API keys)
• Inter-agent communication is designed with enterprise-grade trust models in mind

A2A is an evolving protocol, with ongoing explorations into further enhancements such as:

• A QuerySkill() method for dynamically checking unsupported or unanticipated skills, allowing for more intelligent negotiation between agents.
• Support for dynamic UX negotiation within a task, for example, an agent adding audio or video capabilities mid-conversation.
• Potential extensions for client-initiated methods beyond task management, alongside improvements to streaming reliability and push notification mechanisms.

In short, A2A isn’t just about making agents talk — it’s about enabling the next generation of collaborative, secure, and intelligent AI systems.

If you found this helpful, give it a share or drop a comment.

Thank you for reading! Feel free to connect and reach out on Linkedin  to share feedback, questions and what you build with ADK and A2A